Add Vulkan profile #1567
Add Vulkan profile #1567
Conversation
HansKristian-Work
force-pushed
the
profile
branch
6 times, most recently
from
42568f6
to
07748aa
Compare
Try to align better with profile expectations. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Found during profiles debugging. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Rely on Vulkan 1.2 features here. Avoids problems with profiles layer since it will expose the EXT even if we don't declare it, since it was promoted, but enabling the EXT requires us to enable the features. Spec says that enabling both features is equivalent to enabling the EXT, so this should be okay. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Modern Cbuffer layout is required feature. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We don't fixup interpolation, so this is required. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Check that feature is supported. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For testing profile behavior, it's useful to be able to verify that we reject feature levels when features are limited. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
HansKristian-Work
force-pushed
the
profile
branch
from
07748aa
to
2fbc529
Compare
Does it now? I remember when doing the same for DXVK we'd get validation errors until I also bumped the SPIR-V version. |
It's possible that spec was clarified, but if there's still a VVL error here, that sounds like a VVL bug if anything, but this is explicitly stated in spec. |
| @@ -2067,6 +2070,13 @@ static HRESULT vkd3d_init_device_caps(struct d3d12_device *device, | |||
| physical_device_info->properties2.properties.sparseProperties.residencyNonResidentStrict = VK_FALSE; | |||
| } | |||
|
|
|||
| /* We need independent interpolation to use GPL. */ | |||
| if (!physical_device_info->graphics_pipeline_library_properties.graphicsPipelineLibraryIndependentInterpolationDecoration) | |||
There was a problem hiding this comment.
Is this required even if we compile FS and all vertex stages into one single library?
Spec wording kind of indicates that it is but I don't know if this is really the intent here, but I guess every driver that supports GPL will want to support this bit anyway.
There was a problem hiding this comment.
I looked for an exception, but there is none. Maybe it should be clarified in spec, but most likely drivers have a separate GPL path where they don't do cross stage stuff, and conditionally adding cross stage linking if all stages are present is slightly unexpected.
Supersedes #1210.
This was kinda painful to write. Ended up with more profiles than expected.
The maximum profiles are intended to represent the current state of RADV and NV.
SM 6.2 denorm behavior stuff got extremely messy. I just ignored it and put it in the optimal per-vendor profiles. When NV fixes their drivers, we can do it properly ... The optional feature selection is broken it seems and I couldn't make it work.
Added an auto-generated profile Markdown.
Added some helper scripts to invoke the profiles layer so that it's possible to run the test suite with limited feature sets.
I found misc bugs that way.
Also added a way to check the profiles using the profiles solution. E.g.:
It can dump out debug information to report what is not supported: